FIG. 1 shows a telecommunications network 2. The network 2 comprises a plurality of radio base stations 4, each of which communicates with a plurality of mobile terminals 6 in so-called “cells”. Each radio base station 4 further communicates with a core network 8. For example, where the network 2 is an evolved UMTS terrestrial radio access network (E-UTRAN), the core network 8 comprises an evolved packet core, itself comprising a mobility management entity (MME), a serving gateway and a PDN (packet data network) gateway.
E-UTRAN according to Release 8 of the 3GPP specifications supports bandwidths up to 20 MHz. However, one of the requirements of future releases of this standard is expected to be the support of bandwidths larger than 20 MHz. A further important requirement on such releases is to assure backward compatibility with Release 8. This should also include spectrum compatibility. That would imply that a future-release carrier, wider than 20 MHz, should appear as a number of Rel-8 carriers to a Rel-8 terminal. Each such carrier can be referred to as a Component Carrier. In particular for early deployments of future releases, it can be expected that there will be a smaller number of future-release terminals compared to many legacy Rel-8 terminals. Therefore, it is necessary to assure an efficient use of a wide carrier also for legacy terminals, i.e. that it is possible to implement carriers where legacy terminals can be scheduled in all parts of the wideband future-release carrier.
The straightforward way to obtain this would be by means of carrier aggregation. Carrier aggregation implies that a future-release terminal can receive multiple component carriers, where the component carriers have, or at least have the possibility of having, the same structure as a Rel-8 carrier. Carrier aggregation is illustrated in FIG. 2 where five component carriers 10, each of 20 MHz bandwidth, have been aggregated together to form an aggregated bandwidth of 100 MHz.
In 3GPP Release 8, downlink control signalling is used to support transmission of uplink and downlink data. Release 8 uses downlink L1/L2 control signalling. The downlink L1/L2 control signalling includes downlink scheduling assignments including information required for the terminal to be able to properly receive downlink data transmissions and uplink scheduling grants controlling the uplink transmission activity.
The downlink L1/L2 control signalling corresponds to three different physical-channel types:                The Physical Control Format Indicator Channel (PCFICH), informing the terminal about the size of the control region (one, two, or three OFDM symbols). There is one and only one PCFICH in each cell.        The Physical Downlink Control Channel (PDCCH), used to signal downlink scheduling assignments and uplink scheduling grants. Each PDCCH carries signalling for a single terminal (or a group of terminals). There are typically multiple PDCCHs in each cell.        The Physical Hybrid-ARQ Indicator Channel (PHICH), used to signal hybrid-ARQ acknowledgements in response to uplink UL-SCH transmissions. There are multiple PHICHs in each cell.        
Part of the information transmitted on a PDCCH is the resources used for transmission of the data, expressed as resource blocks. That is, each resource block relates to a particular portion of frequency bandwidth, and a particular interval in time. There are three different possibilities to signal the resource-block allocation type: type 0, 1 and 2. Resource-block allocation types 0 and 1 both support allocations of non-contiguous resource blocks in the frequency domain, while type 2 supports allocations of contiguous resource blocks only.
FIGS. 3a to 3c illustrate the format of the three resource-block allocation message types 0, 1 and 2 respectively.
In resource allocation type 0 (FIG. 3a), an allocation message comprises a type identifier 12 (i.e. identifying resource allocation type 0) and a bit map 14 pointing to resource blocks that are allocated. The size of the bit map is reduced by each bit pointing not to individual resource blocks in the frequency domain, but to groups of a fixed number of contiguous resource blocks. The size of such a group is determined by the downlink cell bandwidth; for the smallest bandwidths there is only a single resource block in a set implying that an arbitrary set of resource blocks can be scheduled, while for the largest cell bandwidths groups of four resource blocks may be used. Thus, the bitmap for a system with a downlink cell bandwidth of 100 resource blocks may be reduced from 100 bits to 25 bits. A drawback though is that the scheduling granularity is reduced; single resource blocks cannot be scheduled for the largest cell bandwidths using allocation type 0.
This is a problem, as in large cell bandwidths a frequency resolution of a single resource block is sometimes useful, e.g. to support small payloads. Resource allocation type 1 addresses this by dividing the total number of resource blocks in the frequency domain into dispersed subsets. The number of subsets is given from the cell bandwidth, with the number of subsets in type 1 being equal to the group size in type 0.
Thus, for the example of a downlink cell bandwidth of 100 resource blocks, as described above, there are four subsets. Within a subset, a bitmap indicates the resource blocks in the frequency domain upon which the downlink transmission occurs.
FIG. 3b shows the resource allocation message structure for resource allocation type 1. The message again comprises a type identifier 16 (identifying type 1) and a bitmap 18 identifying the resource blocks that are allocated. However, one of the requirements on the design of resource allocation type 1 was to maintain the same number of bits in the allocation message as for type 0, without adding unnecessary overhead. The bitmap 18 in resource allocation type 1 is therefore necessarily smaller than in type 0 to allow for the signalling of the subset number in the subset identifier field 20. A consequence of the smaller bitmap 18 is that not all resource blocks in the subset can be addressed simultaneously. To be able to address all resources with the bitmap, there is a flag 22 indicating whether the bitmap relates to the “left” or “right” part of the resource blocks in the subset. That is, further subsets are defined within the original subset.
FIG. 3c shows the structure of a resource allocation message for resource allocation type 2. Unlike the other two types of resource-block allocation signalling, type 2 does not rely on a bitmap. Instead, it encodes the resource allocation as a start position 24 and length 26 of the resource-block allocation. Thus, it does not support arbitrary allocations of resource blocks but only contiguous allocations, thereby reducing the number of bits required for signalling the resource-block allocation.
What is required is a way of signalling resource allocation in a telecommunications network utilizing a plurality of carriers between the radio base station and the mobile terminal.
Two alternatives for L1/L2 control signalling in future releases of the UTRAN as specified in future releases of the 3GPP specifications can be considered (i.e. when signalling on multiple component carriers):    1) Each component carrier has its own PDCCH; if the terminal is scheduled on multiple component carriers, information about that particular component carrier is included on the PDCCH of the same component carrier.    2) PDCCHs on one component carrier can point to resource blocks on multiple component carriers.
In the first alternative, the signalling structure on each component carrier can be identical to Rel-8. However, in the second alternative, one PDCCH needs to be able to point to resource blocks on multiple component carriers. Such a PDCCH therefore needs to be able to point to a larger number of resource blocks than are available on a single component carrier.
Extending the addressing capability in terms of resource blocks can be done by introducing new formats of the control information transmitted on the PDCCH. To be able to allocate resources on all component carriers, the new format needs to be able to address a larger set of resource blocks. As an example, if five carriers of 20 MHz are aggregated, the new format needs to address up to 5×100=500 resource blocks in the frequency domain, compared to 100 in the case of a single 20 MHz carrier only. Hence, the new format will be larger, in terms of the number of bits for control signalling, in order to address the larger number of resource blocks.
However, introducing new formats would require a terminal to monitor multiple formats. This increases the complexity of the terminal as the terminal preferably should monitor also the formats present in Rel-8. If the terminal monitors only the new format(s), the network would be forced to use the new format also for small resource block allocations, resulting in an increase in overhead.